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PREFACE 

This  report  was  prepared  by  the  staff  of  the  Information  Protection  Technology  group  of  the  Advanced 
Technology  Institute  as  part  of  the  Defense  Healthcare  Information  Assurance  Program  (DHIAP).  The 
DHIAP  work  is  supported  by  the  U.S.  Army  Medical  Research  and  Materiel  Command.  As  noted,  the 
views,  opinions  and/or  findings  contained  in  this  report  are  those  of  the  authors  and  should  not  be 
construed  as  official  Department  of  the  Army  position,  policy  or  decision. 

This  report  on  the  DHIAP  Technology  Demonstration,  Prototype  for  Remote  Authentication  Dial-In  User 
Service  (RADIUS),  is  prepared  as  a  report  on  the  selection,  testing,  installation,  and  transition  of  the 
prototype  demonstration  to  operational  Medical  Treatment  Facilities  (MTF).  It  is  written  for  MEDCOM 
and  MTF  management  based  on  lessons  learned  and  experiences  gained  during  the  course  of  designing, 
installing,  and  testing  RADIUS  compliant  systems  in  the  laboratory  and  at  operational  sites.  It  is  written 
as  an  aid  to  understanding  the  basis  of  the  RADIUS  technology,  the  technology  prototyped  and 
demonstrated  at  the  laboratory  and  the  test  sites,  potential  implementation  alternatives,  and  the  costs  in 
dollars  and  personnel  resources  of  providing  services  demonstrated  in  this  prototype. 

The  information  contained  herein  is  drawn  from  many  sources  including  vendors'  literature,  extensive 
correspondence  and  discussion  with  vendor  technical  representatives,  MTF  information  management  staff 
as  well  as  experiences  and  lessons  learned  during  the  course  of  the  installations  and  testing. 

This  report  is  one  piece  of  a  body  of  work  completed  during  Phase  I  of  DHIAP.  The  DHIAP  team  has 
published  two  other  documents  relating  the  work  performed  in  Phase  I  of  DHIAP.  The  DHIAP  RADIUS 
Supplemental  Installation  and  Maintenance  Guide  (ATI  Special  Report  IPS  00-03)  was  developed  as  a 
guide  for  installation  and  configuration  of  the  RADIUS-compliant  system  prototyped  during  the 
technology  demonstration.  It  serves  as  a  supplement  to  existing  Cisco  and  Microsoft  vendors'  instructions. 
Reference  to  that  guide  should  help  the  reader  interested  in  technical  details  to  understand  the  internal 
operations  of  the  hardware  and  software  deployed  in  the  RADIUS-compliant  systems.  The  DHIAP  Phase 
I  Composite  Evaluation  Report  (ATI  Technical  Report  IPS  TR  00-02),  provides  a  compendium  of  the 
findings  and  recommendations  of  the  Information  Security  Evaluations  conducted  at  military  MTF  as  part 
of  DHIAP  Phase  I.  This  report  outlines  vulnerabilities  identified  and  provides  subject-specific 
recommendations  for  remedial  actions.  It  also  outlines  recommended  crosscutting  activities  that  address 
such  organizational  focus  areas  as  policy  definition,  procedure  development,  and  training.  This  report  on 
the  evaluations  provides  insight  into  areas  of  potential  security  vulnerabilities  that  are  not  addressed  by 
this  technology  demonstration. 

Ms.  Lynn  Crane  was  the  principal  author  and  overall  coordinator  for  this  report,  with  significant  technical 
input  from  Mr.  Lane  Melton  and  Dr.  Jack  Stinson.  Other  contributors  included  Mr.  Forrest  Schwengels  of 
the  Advanced  Computing  Technology  staff  of  Lockheed  Martin  Energy  Systems,  Mr.  Thornton  White  of 
Arthur  D.  Little,  Inc.,  and  numerous  members  of  the  Cisco  Technical  Staff.  Mr.  Archie  Andrews  assisted 
in  editing  the  report.  Sarah  Hartline  typed  and  revised  the  many  drafts  of  the  guide  and  prepared  the 
report  for  publication. 


Archie  D.  Andrews 

Principal  Investigator,  Defense  Healthcare  Information  Assurance  Program 
Director,  Information  Protection  Technology 
Advanced  Technology  Institute 
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DHIAP  PHASE  I  TECHNOLOGY  DEMONSTRATION 

PROTOTYPE  FOR  REMOTE  AUTHENTICATION  DIAL-IN  USER  SERVICE  (RADIUS) 


EXECUTIVE  SUMMARY 

In  1997  Congress  recommended  and  funded  a  program  to  develop  and  demonstrate  effective  ways 
to  secure  military  healthcare  information  systems.  The  Defense  Healthcare  Information  Assurance 
Program  (DHIAP)  was  developed  in  response  to  that  recommendation  with  the  purpose  of 
identifying  weaknesses  in  current  medical  information  systems  and  developing  prototype  systems 
to  provide  reliable  access  to  healthcare  information  while  protecting  it  from  unauthorized  access  or 
alteration. 

The  first  step  in  accomplishing  DHIAP’ s  goal  involved  evaluating  existing  military  medical 
information  systems  and  their  operational  environments  at  military  Medical  Treatment  Facility 
(MTF)  sites;  the  DHIAP  evaluation  team  identified  vulnerabilities  in  the  MTF  information 
assurance  capabilities  and  recommended  operational  procedures  and  policies  to  address  those 
vulnerabilities.  The  second  step  was  to  study  the  technical  vulnerabilities  that  were  found  for  areas 
where  application  of  technology  could  reduce  or  even  resolve  significant  exposures.  A  review  of 
alternatives  with  representatives  of  the  MTFs  that  would  serve  as  trial  sites  for  the  technology 
demonstration  resulted  in  the  decision  to  build  a  prototype  that  would  provide  Army-mandated 
compliance  with  the  Remote  Authentication  Dial-In  User  Service  (RADIUS)  standard.  This  report 
provides  the  findings  and  conclusions  of  the  effort  to  develop  the  technology  and  perform  MTF 
trials  of  the  RADIUS-compliant  prototype. 

The  DHIAP  Team  worked  closely  with  MTF  technical  representatives  to  confirm  Army 
requirements  relative  to  the  RADIUS  standard,  then  examined  the  marketplace  for  hardware  and 
software  components  that  met  Army  and  RADIUS  requirements  and  satisfied  many  of  the 
“preferences”  expressed  by  the  MTFs  participating  in  the  effort.  After  building  a  prototype  in  a 
laboratory  environment,  the  Team  performed  local  and  cross-facility  trials.  Finally,  they 
implemented  the  prototype  at  the  MTFs,  tested  it,  built  installation  and  operating  procedures  to 
guide  early  use  of  the  system,  and  transitioned  the  technology  to  the  sites  for  permanent  use  with 
their  remote  dial-in  users. 

The  demonstration  of  DHIAP’ s  prototype  clearly  showed  the  ease  of  implementing  it  in  the 
Army’s  existing  regional  network  environment,  it’s  ability  to  work  within  the  regions’  and  sites’ 
Windows  NT-based  technical  environment,  and,  most  importantly,  its  effectiveness  in  providing 
RADIUS  compliance  for  remote  dial-in  users  of  military  healthcare  systems.  The  demonstration 
sites  are  continuing  to  use  the  prototype  to  control  access  by  remote  dial-in  users  even  though  the 
trials  have  ended;  they  are  making  plans  to  carry  the  technology  forward  with  the  necessary 
changes  in  their  systems  environments. 

Section  IV  of  this  report  provides  high-level  recommendations  for  program  management  and 
programmatics  of  a  broader  implementation  of  the  DHIAP  RADIUS -compliant  prototype  that  will 
produce  a  timely,  efficient  implementation  of  the  technology  across  Army  MTF  sites. 
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PROTOTYPE  FOR  REMOTE  AUTHENTICATION  DIAL-IN  USER  SERVICE  (RADIUS) 


I.  INTRODUCTION 

DHIAP  BACKGROUND 

The  United  States  Congress,  the  Secretary  of  the  Army,  and  the  Chief  Information  Officer  of  the 
U.S.  Army  Medical  Command  recognize  that  the  current  medical  information  systems  are 
vulnerable  to  attacks  on  the  availability,  integrity,  and  confidentiality  of  their  healthcare 
information.  To  address  these  issues,  Congress  recommended  and  funded  a  program  to  develop 
and  demonstrate  effective  ways  to  secure  military  healthcare  information  systems. 

In  their  normal  operation,  healthcare  information  systems  create,  store,  access,  transfer,  and 
exchange  sensitive  but  unclassified  information.  The  challenge  is  to  handle  the  information  in 
such  a  way  as  to  protect  the  privacy,  confidentiality,  and  integrity  of  the  data  while  still 
providing  efficient  and  effective  access  to  authorized  users  when  and  where  needed.  To  meet 
this  challenge  and  identify  the  most  effective  ways  to  integrate  proper  policies,  procedures, 
methods,  and  technologies  into  existing  military  or  healthcare  information  systems  requires  the 
following: 

•  An  understanding  of  present,  near  term,  and  future  policy  and  requirements  for  assuring 
the  privacy  of  healthcare  information; 

•  An  understanding  of  the  present  state  of  the  information  security  within  the  healthcare 
community; 

•  An  analysis  and  documentation  of  functional  requirements  to  improve  requisite  security 
while  minimizing  negative  impact  on  required  operational  effectiveness;  and 

•  A  demonstration  in  the  healthcare  domain  by  installation  and  operation  of  a  prototype  to 
evaluate  the  effectiveness  and  operational  impact  of  proposed  security  improvements. 

The  Defense  Healthcare  Information  Assurance  Program  (DHIAP)  was  developed  to  meet  the 
Congressional  and  Army  goals.  The  purpose  of  DHIAP  is  to  assess  the  present  state  of 
information  security  within  the  military  healthcare  system  and  to  demonstrate  prototype  systems 
that  provide  reliable  access  to  military  healthcare  information  systems  while  protecting  that 
information  from  unauthorized  access  or  alteration. 

One  major  effort  in  accomplishing  the  goals  of  Phase  I  of  DHIAP  involved  evaluating  the 
operational  environments  and  medical  information  systems  at  military  Medical  Treatment 
Facilities  (MTFs)  against  both  expert  knowledge  of  security  practices  that  should  be  in  place  and 
current  Army  regulatory  guidance  for  protection  of  patient  information.  The  goals  of  this 
activity  were  to  determine  vulnerabilities  in  information  assurance  capabilities  and  recommend 
operational  policies  and  procedures  to  address  those  vulnerabilities.1  Known  as  DHIAP’s 
Information  Security  Evaluation  (ISE)  effort,  this  activity  culminated  with  publishing  the  Phase  I 
Composite  Evaluation  Report  (ATI  IPS  TR  00-02).  The  report  documents  the  results  of  the 
evaluation,  outlines  specific  actions  to  address  reported  vulnerabilities,  and  provides 


1  Appendix  A  lists  Army  regulations  and  other  publications  used  as  references  in  this  investigation.  Note  that  the 
pending  legislation  and  regulatory  guidance  of  Health  Insurance  Portability  and  Accountability  Act  of  1996 
(HIPAA),  expected  to  be  effective  during  2000  and  requiring  compliance  about  two  years  afterwards,  will  further 
affect  requirements  for  privacy  of  individually  identifiable  health  information. 
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recommendations  to  management  for  improving  information  protection  within  the  Army's 
medical  organizations. 

The  other  major  effort  of  DHIAP  Phase  I  used  the  ISE  information  as  its  starting  point.  This 
“Technology  Demonstration”  effort  began  by  prioritizing  the  vulnerabilities  relative  to  site 
priorities  and  determining  candidate  efforts  where  application  of  technology  could  demonstrate  a 
significant  reduction  in  (or  resolution  of)  a  significant  exposure.  A  review  of  the  alternatives 
with  MTF  staff  that  would  be  involved  in  the  DHIAP  technology  development  and 
demonstration  effort  confirmed  MTFs’  need  for  authentication,  authorization,  and 
accounting/audit  of  their  remote  access  capabilities  and  resulted  in  the  decision  to  build  a 
prototype  technology  to  comply  with  the  Army  directive  for  Remote  Authentication  Dial-In  User 
Service  (RADIUS).'  This  DHIAP  Phase  /  Technology  Demonstration  Report  provides  the 
background,  findings,  and  results  of  the  prototype  demonstration  effort,  as  well  as 
recommendations  for  adapting  the  DHIAP  prototype  RADIUS-compliant  implementation  to  be  a 
cost-effective,  manageable,  and  dependable  solution  for  the  Army’s  multi-region  medical 
processing  environment. 

PURPOSE  OF  REPORT 

This  report  was  compiled  to  provide  MEDCOM  and  other  military  organizations  with  the  design 
of  DHIAP’ s  RADIUS-compliant  system,  an  assessment  of  current-day  operational  realities  that 
either  aid  or  restrict  its  effectiveness,  and  recommendations  for  action. 

REPORT  ORGANIZATION 

The  following  subjects  are  covered  in  this  report: 

II.  Technology  Demonstration  reviews  the  DHIAP  Phase  I  activities  that  produced  the 
successful  RADIUS-compliant  DHIAP  prototype.  It  outlines  design  requirements  established  by 
MTF  needs  and  the  Army  and  Internet  Engineering  Task  Force  standards  for  RADIUS 
compliance,  summarizes  activities  that  occurred  during  design  and  development  of  the  DHIAP 
RADIUS  prototype,  and  reviews  major  events  of  the  technology  trials  and  transition. 
Appendices  A  through  D  provide  supporting  detail  for  the  material  in  this  section. 

III.  Results  and  Observations  assesses  the  capabilities  of  the  DHIAP  RADIUS-compliant 
prototype  based  on  its  performance  during  the  system  demonstration  activity.  After  examining 
the  prototype’s  fit  to  the  Army’s  mandated  and  operational  technical  environment,  it  reviews  the 
type  of  configuration  that  should  be  installed  at  various  types  of  MTF  sites  and  why.  The  section 
concludes  with  descriptions  of  the  prototype’s  ease  of  installation  and  its  ease  of  operation  and 
maintenance. 

IY.  RADIUS  Implementation  in  the  Army  Medical  Domain  outlines  the  major  programmatic 
considerations  for  a  broad  (e.g.,  regional)  implementation  of  the  DHIAP  RADIUS -compliant 
technology.  It  describes  the  various  options  for  equipment  (and  capability)  distribution  across 
multiple  sites  and  provides  high-level  pros  and  cons  for  selection  of  each  option.  It  provides 
information  on  programmatics  of  a  RADIUS  implementation,  including  cost  analysis,  project 


2  The  DISC4  message  is  included  as  Appendix  B. 
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planning,  and  resources.  It  concludes  by  providing  some  basic  information  on  MTF-level 
considerations  for  staffing  and  training  to  support  the  technology. 

Appendix  A  lists  reference  documents  used  by  the  Team  to  increase  their  understanding  of  the 
existing  and  planned  military  operations,  policies,  and  procedures. 

Appendix  B  is  a  copy  of  the  HQ  DA,  DISC4,  Washington  DC  message,  subject:  Network 
Security  Improvement  Program  (NSIP)  -  Army  Dial-in  Standards  and  Policy,  dtg  231300Z  April 
1999. 

Appendix  C  is  an  excerpt  from  the  Internet  Engineering  Task  Force’s  documentation  of  the 
RADIUS  standard,  outlining  the  purpose  of  RADIUS  and  what  is  meant  by  its  Authentication, 
Authorization,  and  Accounting. 

Appendix  D  is  an  overview  of  the  DHIAP  RADIUS-compliant  prototype’s  equipment 
configuration  and  its  processing  flows  for  RADIUS  Authentication,  Authorization,  and 
Accounting. 

Appendix  E  is  a  listing  of  the  acronyms  and  abbreviations  used  in  this  report. 

INTENDED  AUDIENCE 

This  document  is  a  report  of  a  cost-effective,  efficient  approach  to  implementing  RADIUS- 
compliant  technology  in  the  military  MTF  environment.  There  are  multiple  audiences  for  this 
information: 

•  Because  the  material  could  be  equally  applicable  to  the  operation  of  any  MTF,  individual 
sites  may  be  interested  in  this  report  as  a  resource  for  identifying  and  addressing  a 
methodology  for  protecting  its  data  during  remote  access  by  users. 

•  Because  the  material  describes  demonstration  of  a  successful  RADIUS  implementation  in 
a  regional  MTF  and  its  subordinate  community  hospital,  along  with  suggestions  for 
making  the  tested  implementation  more  flexible  and  dependable  for  a  true  “regional” 
implementation,  higher  echelons  may  use  this  report  in  defining  a  command-wide 
approach  to  implementing  RADIUS  compliance. 

The  DHIAP  Team  has  provided  the  prototype  design  and  recommendations  for  implementation, 
based  on  observations  of  the  participants  and  the  Team,  to  support  Command  action  required  for 
broad  implementation  of  secure  remote  access  by  users. 
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II.  TECHNOLOGY  DEMONSTRATION 

SUMMARY  OF  DHIAP  PROGRAM  ACTIVITIES 

Phase  I  of  DHIAP  consisted  of  four  major  work  activities,  each  designed  to  build  on  the  results 
of  preceding  efforts.  The  first  activity  performed  vulnerability  research  at  selected  Army 
Medical  Treatment  Facilities  (MTFs);  the 
remaining  activities  identified,  developed,  and 
tested  a  prototype  technology  to  address  one  or 
more  of  the  identified  vulnerabilities.  The 
activities  and  their  work  results  are  depicted  in 
Figure  1  and  described  below. 


PROJECT  PARTICIPANTS 

The  DHIAP  RADIUS  demonstration  was 
conducted  under  the  auspices  of  the  Telemedicine 
and  Advanced  Technology  Research  Center 
(TATRC)  of  the  Medical  Research  and  Materiel 
Command  (MRMC).  The  DHIAP  Team  of 
information  protection,  security,  and  healthcare  experts  included  the  following  organizations: 

•  ATI  (Advanced  Technology  Institute),  Information  Protection  Technology  Group 

•  LMES  (Lockheed  Martin  Energy  Systems),  Data  Systems  Research  Division 

•  SEI  (Software  Engineering  Institute),  Networked  Systems  Survivability  Program 

•  ADL  (Arthur  D.  Little,  Inc.),  Program  Management  Office 

•  Government  representatives  from  TATRC/MRMC 

The  Army  organizations  that  participated  in  the  DHIAP  RADIUS  demonstration  effort  are: 

•  Dwight  David  Eisenhower  Army  Medical  Center  (DDEAMC)  at  Fort  Gordon, 
Georgia 

•  Winn  Army  Community  Hospital  (WACH)  at  Fort  Stewart,  Georgia 

•  Southeast  Region  Medical  Command  (SERMC)  at  Ft.  Gordon,  Georgia 

DDEAMC  is  the  regional  medical  center  for  Army  Medical  Command's  Southeast  region. 
WACH  is  a  community  hospital  within  the  region.  SERMC  has  regional  staff  responsibility  for 
medical  operations,  to  include  information  processing  among  the  region’s  facilities. 

TECHNICAL  ASSESSMENT 

In  this  effort  the  DHIAP  Team’s  experts  in  system  security  and  healthcare  facility  administration 
performed  onsite  technical  evaluations  at  two  military  MTFs  to  identify  healthcare  information 
security  issues  and  requirements.  In  addition  to  generating  recommendations  for  improvements 
in  policy,  operations/procedures,  personnel/staffing,  and  technology,  the  Team’s  analysis  of 


Activity 

Technical  Assessment] 


Result 


•  Information  Security  Issues,  Requirements 

•  Recommendations 

(Policy,  Operations,  Personnel,  Technology) 

•  Technical  Vulnerabilities 


[  Prototype  Development j 


Prototype  Decision:  RADIUS 
Prototype  Design,  Refinement  w/MTFs 
Prototype  Development,  Evaluation 


Demonstration 


Multi-site  Demo  of  Prototype 
Policy/Procedure  Development 
Prep  for  Transition  to  MTFs 


( Technology  Transition ] 


MTF  Installation  /  Trials 
Operational  Feedback 
Recommendations  to  TATRC 


Figure  1  -  Summary  of  DHIAP  Phase  I  Activities 
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findings  provided  specific  insight  into  the  sites’  technical  system  vulnerabilities.  Detailed 
technical  recommendations  were  provided  directly  to  the  sites.  A  composite  report  of  problem 
areas  identified  and  recommendations  for  remedial  action  was  provided  to  TATRC  as  ATI  IPS 
TR  00-02,  DHIAP  Composite  Evaluation  Report.  As  a  result  of  the  technical  evaluations  of  the 
MTF  sites,  the  DHIAP  Team  was  able  to  recommend  candidate  demonstration  projects  to 
improve  certain  aspects  of  MTF  security. 

PROTOTYPE  DESIGN  AND  DEVELOPMENT 

Prototype  design  and  development  consisted  of  working  with  the  sites  to  analyze  the  technical 
and  operational  requirements  for  a  demonstration  system,  investigate  the  various  possible 
approaches  to  satisfying  the  requirements,  present  the  options  to  the  affected  sites  and  to 
TATRC,  install  and  demonstrate  the  capability  in  a  laboratory  environment,  install,  test,  and 
configure  the  prototype  capability  at  the  sites,  and  transition  the  operational  systems  to  the  sites. 

Selection  of  RADIUS  as  the  DHIAP  Demonstration  Prototype 

After  a  number  of  information  protection  vulnerabilities  were  identified  during  the  Information 
Security  Evaluations  (ISEs)  conducted  earlier  by 
the  DHIAP  Team  at  two  military  MTFs,  the  Team 
prioritized  these  vulnerabilities,  using  criteria 
shown  in  Figure  2.  Prioritization  was  also 
influenced  by  the  Team’s  opinion  of  how  best  to 
make  a  difference  in  information  security  at  the 
MTF.  Armed  with  knowledge  of  the  high  priority 
vulnerabilities,  the  team  performed  research  to 
identify  technology  development  efforts  that 
would  address  them.  Finally,  they  returned  to 
sites  that  had  participated  in  the  ISEs  to  conduct 
working  sessions  and  targeted  analyses  with  the  sites’  technical  staffs  to  ensure  that  they  had 
identified  all  relevant  technical  and  operational  issues. 

The  Team’s  initial  technology  proposal  to  the  MTFs  was  to  implement  secure  e-mail  service 
using  secure  socket  layer  (SSF)  sessions  in  order  to  protect  information  in  transit  between  the 
remote  users  and  the  MTF  computing  environment.  MTF  staff  responded  that  they  had  already 
begun  to  implement  SSF  for  electronic  mail,  but  needed  technical  assistance  to  comply  with  the 

a 

Army  directive  for  implementing  the  Remote  Authentication  Dial-In  User  Service  (RADIUS). 
Their  goal  in  implementing  this  capability  was  to  provide  the  site  with  much  improved 
identification  and  authorization  of  the  remote  users  who  access  hospital  systems  via  dial-in. 

MTF  staff,  TATRC,  and  the  DHIAP  Team  agreed  that  DHIAP’s  Prototype  Demonstration  would 
implement  a  RADIUS-compliant  server  capability  fulfilling  the  Army’s  requirement  for 
identification  and  authentication  of  dial-in  users.  As  an  important  extension  to  the  RADIUS 
demonstration,  they  arranged  for  the  implementation  to  involve  both  a  regional  medical  center 
and  an  associated  community-level  MTF  and  for  testing  and  trials  of  the  technology  to  include 
both  local  and  cross-facility  communications. 

3  HQ  DA,  DISC4,  Washington  DC  message,  subject:  Network  Security  Improvement  Program  (NSIP)  -  Army  Dial- 
in  Standards  and  Policy,  dtg  231300Z  April  1999;  the  message  is  included  as  Appendix  B. 


•  Relevance  to  MTF  needs 

•  Relevance  to  TATRC  mission 

•  MTF  authority  to  direct  and  implement  change 

•  Cost 

•  Complexity 

•  Existence  of  a  technical  solution 

Figure  2  -  Criteria  for  Prioritizing  Information 
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Prototype  Design 

Design  of  the  DHIAP  prototype  technology  began  with  documenting  technical  security 
requirements  outlined  in  the  Army’s 
RADIUS  guidance.  Requirements 
outlined  in  the  Internet  Engineering  Task 
Force  (IETF)  specification  of  the  RADIUS 
standard4  added  some  detail  to  the  design, 
and  the  operational  requirements  and 
preferences  noted  during  the  technical 
research  with  trial  site  MTFs  further 
enhanced  the  documentation.  Figure  3 
summarizes  the  Army’s  requirements  for 
RADIUS  implementation,  along  with 
requirements  added  by  the  MTFs  that 
would  be  testbeds  for  the  DHIAP 
prototype  demonstration.  The  MTFs’  core 

selection  criteria  included  compatibility  Figure  3  _  Army  and  MTF  Requirements  for  the  DHIAP 
with  the  MTFs’  existing  systems,  support  prototype 
for  browser-based  administration,  support 

for  remote  auditing,  and  minimizing  the  MTFs’  cost  of  follow-on  support.  It  was  also  important 
that  the  selected  technology  support  growth  in  the  number  of  lines  and  types  of  communications. 

Armed  with  an  understanding  of  requirements,  the 
Team  searched  the  marketplace  for  compliant 
components.  Their  resources  included  the  Internet, 
technical  journals,  contact  with  vendors,  and 
discussions  with  personal  contacts  that  the  Team 
members  considered  experts  in  the  router  and 
computer  security  industry.  The  alternatives 
considered  are  listed  in  Figure  4. 

Based  on  evaluation  of  the  capabilities  of  the 
compliant  components,  knowledge  of  the  technical 
skills  available  within  the  MTFs’  Information  Management  Divisions,  awareness  of  components 
already  in  place  at  the  MTFs,  and  their  own  personal  experience  in  using  many  of  the  candidate 
tools,  the  Team  recommended  that  the  technical  solution  for  the  RADIUS  prototype  be  the  Cisco 
3600  series  router  with  an  Intel-based  computer  running  Windows  NT  Server  and  CiscoSecure 
software. 

Prototype  Development  and  Evaluation 

DHIAP  prototype  systems  were  initially  installed  at  Fockheed  Martin  Energy  Systems  in  Oak 
Ridge  TN  and  the  Advanced  Technology  Institute  in  North  Charleston  SC.  These  laboratory 
installations  highlighted  situations  that  were  likely  to  arise  later  during  installation  at  MTFs.  In 
addition,  they  gave  the  system  developers  and  component  vendors  the  opportunity  to  test  all  the 
system  options  and  to  make  configuration  recommendations  prior  to  installing  the  systems  in  an 


4  Appendix  C  contains  an  overview  of  the  IETF  RADIUS  standard. 


E  VOP  RADIUS  Server  --  Vircom  Products 
E  Total  Control  Access  Platform  --  3COM 
E  Remote  Authentication  Dial-in  User  Services  --  Bay  Networks 
E  MiniArray  III  -  MultiTech  Systems 
E  PortMaster  --  Lucent  Technologies 
E  Remote  Access  Server  --  Microsoft 

0  CiscoSecure  -  CISCO  Systems 

^ _ ^ 

Figure  4  -  Technology  Alternatives  Reviewed 
by  the  DHIAP  Team 


Army  RADIUS  Requirements  idisc4 message,  231300Z apr 99) 

•  Use  standalone  modems  and  modem 
systems  that  authenticate  using  RADIUS 

T  nocSVtfOf'Cf  7 

•  Base  Authentication  on  a  unique)  _ A/* 

User  ID/Password  combination 


Require  at  least  8  randomly- 
lenerated  alphanumeric  characters 
Expire  after  6  months 


Configure  RADIUS  for  Accounting  I  Accounting  X  ldentify  "h°  lo99sd  in  dnd  " hd "■ 

A  additional  useful  information 

Support  remote  auditing  for  compliance  with  the  *  Retain  accounting  log  file  for  at 
Army’s  Identification  and  Authorization  standards  least  one  year 


Additional  MTF  Requirements 


Support  24  discrete  dial-in,  voice-grade  POTS  lines 
Allow  for  growth  in  number  of  lines  and  types  of  connections 

Support  remote  management;  minimize  burden/cost  of  administration  and  support 
Allow  for  support  of  additional  technologies  in  the  future  (e.g.,  tokens,  smart  cards) 

Single-vendor  software  solution 
Equipment  mounted  in  a  rack 


•  Select  technology  that  complements  T  prefer 
existing  technical  environment 


ATI  IPT  TR  00-04 


Page  7 


DHIAP  PHASE  I  TECHNOLOGY  DEMONSTRATION 

_ PROTOTYPE  FOR  REMOTE  AUTHENTICATION  DIAL-IN  USER  SERVICE  (RADIUS) 

operational  environment.  The  laboratory  testing  provided  the  opportunity  to  evaluate  the 
suitability  of  the  system  relative  to  design  requirements.  Concurrent  with  the  installation  and 
testing  period,  the  prototype  design  and  configuration  recommendations  were  informally 
evaluated  by  individuals  from  the  Software  Engineering  Institute  for  fit  to  the  stated 
requirements  and  for  the  impact  on  enhanced  security.  The  proposed  prototype  was  considered  to 
meet  the  functional  requirements  as  stated.  Specifics  of  the  design  and  processing  of  the 
prototype  are  provided  in  Appendix  D. 

DEMONSTRATION 

The  Team’s  evaluation  of  the  RADIUS  capabilities  in  the  multi-site  lab  environment  showed 
connection  of  a  dial-in  user  through  a  RADIUS  prototype  configuration  consisting  of  both  a 
UNIX  system  emulating  a  CHCS  Telnet  connection  and  a  Web  Server/NT  Server  configured  to 
represent  an  MTF's  Exchange  Web  Server.  The  DHIAP  Team’s  demonstration  of  this  capability 
to  an  audience  that  included  TATRC  program  managers  and  the  technical  staff  from  the  test  sites 
resulted  in  a  validation  and  verification  of  the  prototype’s  capabilities  for  authentication, 
authorization,  and  accounting  of  remote  access  dial-in  users.  The  successful  laboratory 
demonstration  provided  the  sites  with  an  understanding  of  equipment  capabilities  and  led  to  their 
agreement  to  install  an  Initial  Operational  Capability  (IOC)  at  their  sites. 

The  systems  were  installed  at  the  identified  test  sites  shortly  after  completion  of  the  lab 
demonstration,  and  the  MTFs  were  given  an  IOC  to  provide  an  opportunity  to  become  familiar 
with  system  operation,  plan  for  operational  procedures,  and  plan  for  the  migration  of  their  user 
population  to  the  new  capability. 

TECHNOLOGY  TRANSITION 

Following  installation,  the  DHIAP  Team  trained  MTF  staff  on  the  installation,  configuration, 
operation,  and  maintenance  of  the  system.  In  addition,  the  Team  reviewed  the  sites’  policy  and 
procedures  for  support  of  secure  system  operations.  The  MTF  sites  operated  the  RADIUS- 
compliant  systems,  configured  their  remote  dial-in  users,  produced  user  guidance,  and  monitored 
the  remote  users’  activity  in  accessing  MTF  systems.  Full  Operational  Capability  (FOC)  was 
scheduled  for  approximately  30  to  45  days  following  the  IOC. 

Soon  after  implementation,  the  sites  were  able  to  transition  the  DHIAP  RADIUS-compliant 
system  from  testing  to  full  operational  status.  MTF  staff  enhanced  their  operational  procedures 
and  documentation  while  the  DHIAP  Team  used  the  MTFs’  feedback  on  their  operational 
experience  with  the  technology  as  the  basis  of  their  recommendations  for  the  Army’s  future 
enhancement  of  the  DHIAP  RADIUS  prototype  and  its  related  policies  and  procedures. 
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III.  RESULTS  AND  OBSERVATIONS 

The  architecture  and  components  of  the  prototype  developed  for  trials  at  DDEAMC  and  WACH, 
the  Army  MTFs  participating  in  the  DHIAP  RADIUS  demonstration,  are  suitable  for  use  in  other 
MTFs.  The  DHIAP  prototype  meets  the  Army  requirements  for  modem  dial-in  standards  and 
policy  (see  Appendix  B),  in  which  the  RADIUS  standard  was  selected  as  the  required  method 
for  implementing  authentication,  authorization  and  accounting.  Table  1  below  provides  a 
comparison  of  the  Army  requirement  for  a  dial-in  system  (based  on  the  Army  message  and  the 
RADIUS  standard)  and  summarizes  the  DHIAP  prototype’s  satisfaction  of  these  requirements. 
The  DHIAP  prototype  provides  flexibility  for  Army  facilities  while  supporting  the  Army's 
requirements  for  RADIUS-compliant  systems. 


Table  1  -  Army  Dial-in  User  Requirements  vs.  DHIAP  RADIUS  System 


Army  Requirements  for  Dial-in  Users5 

DHIAP  RADIUS  System  Implemented 

Standalone  modems  and  modem  systems  with 
dial-back  capability  that  authenticate  using 
RADIUS  are  the  only  allowable  modems. 

DHIAP  prototype  implementation  adheres  to  the  RADIUS 
standard.  It  is  a  site  implementation  responsibility  to 
assure  that  all  modems  go  through  RADIUS. 

Dial-in  operations  will  be  authenticated  with  a 
unique  user-id  and  password. 

User  IDs  and  Passwords  are  unique  and  may  be  stored  on 
either  the  AAA  Server  or  the  region's  NT  User  Database. 

Passwords  shall  be  at  least  eight  randomly 
generated  alphanumeric  characters. 

Minimum  password  length  is  selectable  on  both  the  AAA 
server  and  the  region's  NT  Primary  Domain  Controller. 

Passwords  shall  be  passed  in  encrypted 
format. 

Passwords  are  sent  between  NAS  and  AAA  Server  in 
encrypted  format. 

Passwords  shall  reflect  the  current  Anny 
password  expiration  policy  of  6  months. 

Password  expiration  time  is  selectable  on  both  the  AAA 
Server  and  the  region’s  NT  Primary  Domain  Controller. 

RADIUS  software  shall  be  configured  for 
accounting. 

Multiple  accounting  logs,  configurable  by  the  system 
administrator,  are  maintained. 

Accounting  logs  will  show,  at  a  minimum, 
who  logged  in  and  when;  log  files  will  be 
retained  for  a  year. 

Accounting  information  includes  User  ID,  session  start 
date  and  time,  session  end  date  and  time,  user  IP  address, 
NAS  port,  and  failed  logins;  system  configuration  changes 
are  also  logged.  The  system  administrator  determines  the 
schedule  for  log  file  backup  and  archiving;  logs  may  be 
backed  up  to  either  a  central  repository  on  the  network  or  a 
dedicated  tape.  It  is  a  site  responsibility  to  store  logs  for  at 
least  a  year. 

Servers  will  be  remotely  audited  to  ensure  all 
standards  established  for  Army  Identification 
and  Authorization  are  met. 

A  browser  interface  provides  remote  access  to  log  files; 
remote  privileges  are  configurable. 

The  DHIAP  RADIUS-compliant  prototype  is  designed  to  meet  RADIUS  standards,  assuring  that 
the  remote  dial-in  users  who  request  access  to  the  MTF  network  and  other  military  network 
resources:  (1)  are  who  they  claim  to  be,  and  (2)  obtain  access  only  to  resources  approved  for 
their  use  by  dial-in.  Access  by  the  remote  user  is  logged  to  a  RADIUS-compliant  accounting 
log. 

In  addition  to  Army  requirements,  the  information  systems  groups  at  the  MTFs  and  regional 
levels  have  their  own  “local”  preferences  for  hardware/software  features  and  capabilities.  Two 
important  factors  about  the  MTF  environment  are  that  information  technology  staff  at  MTF  and 
region  levels  have  limited  administrative  resources  and  there  is  a  need  for  future  expansion  of 
capabilities  of  the  RADIUS-compliant  system.  The  configuration  selected  by  DHIAP  for  the 


5  Summarized  from  Army  HQ  DA  message,  dated  23  April  1999  (see  Appendix  B) 
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RADIUS-compliant  system  will  support  the  local  requests  by  providing  the  additional  features 
summarized  in  Table  2. 


Table  2  -  MTF-Requested  Features  of  the  DHIAP  RADIUS-Compliant  System 


Type 

Feature 

System 

Administration 

•  Maintenance  overhead  is  reduced  by  use  of  hardware  and  software  common  in  SERMC: 
Windows  NT  Server  software,  CISCO  Router,  and  Cisco  IOS  software 

•  Administrative  burden  is  reduced  by  authenticating  users  against  SERMC’ s  existing 
Windows  NT  Domain  Name/Password  database 

•  Local  and  remote  network  administration  are  supported  by  the  browser  interface 

Flexibility  / 
Extensibility 

•  Support  for  the  expansion  of  security  features  through  use  of  third-party  token-card  servers 
(SecuiID,  Enigma  Logic,  SecureNet,  and  any  hexadecimal  X.909  devices) 

•  Support  for  time-of-day  access  control,  providing  day,  time  and  duration  control 

•  Support  for  lOBaseT  and  100BaseT  network  connections 

•  Scalable  implementations  to  support  clinic,  hospital  and  region  locations 

•  Support  for  interconnected  multi-site  implementations 

•  Support  for  minimum  configurations  at  smaller  sites 

•  Support  for  redundancy  through  network  connectivity 

These  features  minimize  the  amount  of  additional  hardware  and  software  training  required  to 
support  the  RADIUS -compliant  system  without  limiting  the  technology’s  expansion  and 
scalability. 


MINIMUM  CONFIGURATION 

The  DHIAP  prototype  configurations  installed  at  each  of  the  two  trial  sites  included  full 
capabilities  in  order  to  allow  thorough  testing,  initially  as  standalone  systems  and  then  as 
cooperating  systems  on  a  network.  In  the  prototype  configuration,  the  AAA  Server  manages  the 
RADIUS  authentication  functions,  while  the  NAS  provides  connectivity  for  the  remote  dial-in 
user  and  manages  the  user’s  access  to  authorized  resources.  A  NAS  may  be  co-located  with  the 
AAA  Server  that  performs  its  authentication  or  it  may  instead  rely  on  a  remotely  located  AAA 
Server  for  this  service.  (See  Appendix  D  for  a  complete  description  of  AAA  Server  and  NAS 
processing.) 

A  “regional”  implementation  for  three  or  more  MTFs  could  take  a  different  approach  from  that 
used  in  the  DHIAP  demonstration.  That  is,  an  economical  regional  implementation  would  place 
a  complete  configuration  (AAA  Server  and  NAS)  at  a  limited  number  of  locations  and  minimal 
configurations  (NAS-only)  at  all  other  sites.  In  this  scenario,  the  complete  configurations 
remotely  support  the  sites  that  have  minimal  configurations.  This  concept  is  discussed  further  in 
Section  IV,  “RADIUS  Implementation  in  the  Army  Medical  Domain.” 

The  hardware  and  software  used  in  the  DHIAP  demonstration  was  illustrated  and  their 
processing  described  in  Appendix  D;  the  same  components  are  listed  in  Table  3  below  in  the 
“Demonstration  Prototype  /  Complete  System”  column.  Table  3  indicates  differences  in  the 
equipment  installed  at  “complete”  vs.  “remote”  sites,  and  provides  in  the  “Comments”  column 
relevant  information  about  the  flexibility  of  the  component  or  its  features. 
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Table  3  -  DHIAP  RADIUS  Hardware/Software  Components 


System 

Demonstration  Prototype  / 
DHIAP  Complete  System 
AAA  Server  and  NAS 

Remote 

Site 

NAS-Only 

Comments 

AAA 

Server 

Intel-based  PC  with  500  MHz 
processor,  128  MB 
memory6 

NONE 

■  PC  processor  and  memory  affect  the  processing 
time  required  to  resolve  authentication  requests 

■  Because  the  PC's  workload  (which  is  limited  to 
authentication/logging  activities  only)  is  light, 

DHIAP  implemented  NT  Server  software  on 
workstation  hardware  instead  of  the  more  expensive 
server  hardware 

■  20  GB  hard  drive  (or 
greater) 

Disk  size  requirement  varies  with  amount  of  logging 
(i.e.,  number  of  concurrent  dial-ins)  and  frequency  of 
log  archiving 

-  12/24  GB  DAT  (tape)  drive 
(or  greater) 

DAT  is  used  for  hard  drive  backup;  note  that  local 
procedure  to  back  up  to  existing  Network  Archives 
may  replace  need  for  tape 

Windows  NT  Server  software 

CiscoSecure  software 

NAS 

Cisco  3640  router 

■  Analog  modem  bank  (56  KB 
modems  in  groups) 

■  Other  features:  10/100  MB 
Ethernet  card,  16  MB  non¬ 
volatile  memory 

Cisco  IOS  software 

SAME 

■  Modem  banks  include  8,  16,  24,  or  32  modems 

■  More  than  32  modems  may  be  provided  by 
installing  multiple  NAS  Servers  at  a  site 

■  Interface  cards  for  ISDN  and  T 1  dial-in  lines  may 
also  be  used  in  the  NAS  with  a  corresponding 
reduction  in  the  number  of  available  modem  banks 

UPS 

1400  VA 

SAME 

If  AAA  and  NAS  are  attached  to  a  pre-existing  source 
of  uninterruptible  power,  UPS  is  unnecessary 

EASE  OF  INSTALLATION 

Implementing  the  DHIAP  technology  is  a  matter  of  installing  and  configuring  its  commercial 
off-the-shelf  tools.  As  with  all  technology  installation,  staff  members’  ability  to  apply  related 
experience  generally  reduces  the  time  and  complexity  of  the  task.  By  selecting  components  that 
were  closely  related  to  the  products  already  installed  in  the  MTFs,  the  DHIAP  Team  was  able  to 
take  advantage  of  the  MTF  Information  Management  staffs’  existing  technical  expertise. 

The  learning  curve  for  installing  and  configuring  the  DHIAP  RADIUS-compliant  system  is 
greatly  reduced  when  the  system  administrator  has  prior  experience  with  the  Windows  NT 
Server  and  Cisco  IOS  operating  systems.  This  knowledge,  used  in  conjunction  with  the  DHIAP 
RADIUS  Supplemental  Installation  and  Maintenance  Guide  (ATI  Special  Report  IPS  00-03)  and 
applicable  vendor  documentation,  should  lead  to  a  straightforward  installation.  A  system 
administrator  who  has  successfully  installed  one  DHIAP  RADIUS-compliant  system  should 
require  minimal  additional  knowledge  to  install  systems  at  additional  sites.  An  administrator 
with  no  experience  in  Windows  NT  or  Cisco  IOS  software  will  require  outside  assistance  from 
the  vendors  or  other  experts. 


6  Other  features  of  the  PC  include:  CD-ROM  drive,  3.5  diskette  drive,  Ethernet  card,  keyboard,  mouse,  and  17" 
monitor 
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EASE  OF  OPERATION  AND  MAINTENANCE 

Support  for  Remote  System  Users 

A  remote  user’s  computer  (home,  laptop,  etc.)  must  be  configured  as  a  dial-in  client  before  it  can 
be  used  for  remote  access  to  MTF  systems.  The  configuration  is  a  straightforward  process; 
detailed  procedures  for  configuring  Windows  95,  98,  and  NT  dial-in  clients  are  included  in  the 
DHIAP  RADIUS  Supplemental  Installation  and  Maintenance  Guide  (ATI  Special  Report  IPS  00- 
03)  or  in  Microsoft  documentation.  Once  the  user’s  client  machine  has  been  configured,  there 
should  be  little  or  no  need  for  change. 

From  the  point  of  view  of  the  remote  user,  dial-in  processes  and  procedures  under  the  RADIUS- 
compliant  approach  are  similar  to  methods  used  previously.  Once  the  dial-in  connection  is 
established,  the  user’s  view  and  operation  of  the  accessed  systems  is  similar  to  operation  at  the 
work  location.  One  important  difference  to  the  user  is  that  access  to  particular  systems  used 
locally  may  be  denied  when  dialing  in  from  a  remote  location.  For  example,  user  access  to  a 
system  such  as  CHCS  might  be  necessary  for  day-to-day  work  in  a  nursing  unit  but  inappropriate 
for  access  from  home. 

Support  of  User  Accounts 

Administration  of  user  accounts  (i.e.,  the  User  IDs  and  Passwords)  requires  minimal  effort  when, 
as  occurs  in  SERMC’s  DHIAP  implementation,  AAA  Server  user  authentication  is  performed 
against  the  NT  User  Database  on  the  region’s  NT  Domain  Controller.  In  addition  to  holding  the 
user’s  User  ID  and  Password,  the  NT  User 
Database  holds  an  indicator  of  whether  the  user 
should  be  allowed  to  access  the  network 
remotely;  if  the  NT  indicator  is  set  to  deny 
remote  access,  the  user  will  fail  the  RADIUS 
authentication  process  and  network  access  will 
be  denied. 

Figure  5  depicts  relationships  among  the 
system  resources  involved  in  the  DHIAP 
authentication  that  is  based  on  the  region’s  NT 
User  ID/Password  structure.  To  obtain  access 
to  system  resources,  a  user  must  either  have  Figure  5  -  DHIAP’s  Use  of  Region’s  NT  Structure 
been  predefined  in  the  AAA  Server’s  User 

Database  or  have  been  authenticated  against  the  NT  User  Database  as  an  NT  user  who  is 
allowed  remote  access.  As  described  previously,  authenticated  remote  users  are  given  the  type 
of  access  dictated  by  the  User  Group  entry  in  the  AAA  Server’s  User  Database  entry  (the 
“reference  to  user  entries  in  NAS  ACL”).  If  no  AAA  entry  exists  for  the  remote  user,  the 
RADIUS-compliant  system  temporarily  assigns  the  user  to  a  “default”  User  Group  that  permits 
limited  forms  of  access. 


NT  User  ID/Password 

Remote 
User 

Access  to  system  resources  is  governed  by 
AAA 's  User  Access  entry 


AAA  “Default  User”  access  permissions 


NT  Server 

(NT  Domain  Controller) 


Accounting  Log  File 

•  NT  User  ID 

•  Session  statistics 


•  User  IDs  match  “ 

•  Password  is  valid 

•  Remote  access  is  permitted 


NT  USER  DATABASE 

■  NT  User  IDs/  Passwords 
1  Remote  Access  Permission  (Y,N) 


7  Although  procedure  calls  for  all  of  a  region's  User  IDs/Passwords  to  be  maintained  on  its  NT  User  Database,  it  is 
possible  (but  not  recommended)  for  the  system  administrator  to  record  a  User  ID/Password  directly  on  the  AAA 
Server’s  User  Database.  This  might  be  done  as  a  temporary  measure  (e.g.,  to  permit  short-term  network  access  for  a 
known  and  approved  non-NT  user). 
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Upon  receiving  appropriate  instruction,  a  system  administrator  can  move  the  user  to  a  predefined 
User  Group  that  permits  the  type  of  access  that  is  more  appropriate  to  the  user’s  role  at  the 
facility.  (Note  that  most  types  of  access  permitted  at  a  site  can  typically  be  provided  with  a 
relatively  small  number  of  CiscoSecure 
user  groups.)  Figure  6  provides  an 
example  of  the  types  of  access  permissions 
that  might  be  made  available  to  different 
types  of  users  at  a  facility.  In  this  scheme, 
individuals  with  an  “office  worker”  type  of 
job  might  be  assigned  to  a  User  Group  that 
allows  e-mail  and  Internet  access,  while  a 
“physician”  might  be  in  another  group  that 
allows  e-mail,  Internet,  and  CHCS  access. 

Categorization  of  individuals  into  access  groups  eases  the  burden  placed  on  system 
administrators  and  improves  accuracy  when  working  with  a  large  number  of  users. 

System  administrators  use  a  CiscoSecure  browser-based  interface  to  add,  change,  and  delete  user 
access  permissions;  the  design  of  the  interface  makes  this  maintenance  an  efficient  process.  Once 
a  particular  group’s  access  rights  have  been  defined,  assigning  existing  users  to  the  group  is 
accomplished  by  associating  the  user  with  the  appropriate  group.  Each  user  inherits  the 
privileges  allowed  for  the  group;  there  is  no  need  to  create  and  maintain  separate  privilege  lists 
for  each  individual  remote  user. 

Support  of  Accounting  Logs 

The  system  administrator’s  work  with  the  CiscoSecure  Accounting  Log  function  begins  with 
defining  the  information  to  be  logged.  The  system  administrator  uses  the  CiscoSecure  browser 
interface  to  modify  both  the  types  of  logs  that  are  maintained  and  the  type  of  information  logged. 
Ongoing,  the  system  administrator  monitors  the  logging  activity,  works  as  needed  with  the 
information  captured  on  the  logs,  and  regularly  archives  (or  backs  up)  the  log  files. 

In  monitoring  the  logs,  the  system  administrator  should  regularly  review  the  captured 
information  to  identify  unusual  circumstances  and  initiate  appropriate  action.  As  with  log 
maintenance,  the  monitoring  of  accounting  logs  is  performed  using  the  browser-based  interface. 
Certain  log  monitoring  activities  may  be  automated:  the  system  administrator  may  customize 
CiscoSecure  to  send  an  electronic  alert  when  a  particular  type  of  activity  occurs  (e.g.,  excessive 
login  attempts).  CiscoSecure  will  then  generate  an  alert  via  e-mail  or  pager  to  predefined 
destinations  as  timely  notification  that  the  questionable  event  has  occurred. 

Accounting  logs  must  be  periodically  archived  to  backup  storage  media.  Frequency  of  archiving 
is  based  on  site  preference,  typically  associated  with  the  file’s  size  relative  to  space  available. 
Log  retention,  set  by  the  system  administrator  using  CiscoSecure’ s  browser,  may  be  based  on 
time  or  file  size,  or  may  be  left  under  manual  control.  The  method  of  archiving  is  also  a  site- 
dependent  decision:  one  approach  is  to  archive  the  logs  as  part  of  regular  network  backups  at  the 
site,  another  is  to  archive  to  tape  (a  tape  drive  is  included  in  the  DHIAP  complete  system’s 
configuration  for  this  purpose). 


Group# 

MTF  Role 

Access  Privileges 

Default 

Undefined  or 
Uncategorized  NT  Users 

E-mail 

10 

System  Administrators 

All  systems  and  privileges  available  on  their 
office  computers 

20 

Medical  Staff 

E-mail,  Internet,  and  CHCS 

30 

Staff 

E-mail  and  Internet 

40 

Command  Staff 

All  systems  available  on  their  office 
computers  (e.g.,  E-mail,  CHCS,  network  files) 

Figure  6  -  Typical  Group  Privileges  for  an  MTF 
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IV.  RADIUS  IMPLEMENTATION  IN  THE  ARMY  MEDICAL  DOMAIN 

Implementing  effective  solutions  for  securing  military  healthcare  information  systems  is  one  of 
the  primary  objectives  of  DHIAP.  DHIAP's  investigations  of  information  protection 

o 

vulnerabilities  at  representative  regional  and  community  hospital  MTFs,  and  its  demonstration 
of  a  prototype  technology  for  authenticating  and  authorizing  remote  system  users,  can  provide 
useful  direction  and  tools  for  Army  MTFs. 

DHIAP’s  RADIUS-compliant  prototype  was  designed  for  simple  insertion  at  the  point  of  dial-in 
access  of  an  existing  network  structure.  It  was  demonstrated  in  SERMC  where  the  network 
structure  is  based  on  Windows  NT  4  and  system  users  are  defined  within  the  region  NT  system’s 
Domain  Controller.  Like  all  Army  medical  facilities,  SERMC  is  part  of  MEDNET’s  regional 
and  command-wide  communications  infrastructure.  Since  the  other  Army  medical  regions  use  a 
similar  pattern  of  centralized  control  over  user  access  permissions,  it  is  likely  that 
implementation  of  the  DHIAP  RADIUS-compliant  prototype  would  be  straightforward 
throughout  MEDCOM. 

It  is  important  that  a  broad  implementation  of  the  DHIAP  RADIUS -compliant  technology  (i.e., 
multi-region  or  command- wide)  be  planned  and  overseen  by  a  central  coordinating  authority.  As 
outlined  in  this  section,  critical  subjects  such  as  technical  approach,  project  planning,  equipment 
configuration  and  acquisition,  procedures,  and  operational  staffing  are  handled  more 
economically  and  efficiently  by  the  distributed  implementation  teams  when  guidelines  have  been 
provided  by  a  central  authority.  Project  oversight  by  the  same  authority  would  assure  that 
coordinated  efforts  proceed  according  to  a  plan. 

For  simplicity  and  clarity,  the  following  analysis  and  recommendations  are  based  on  a 
MEDCOM  implementation.  It  is  recognized  that  the  central  coordinating  authority  may  be  a 
function  of  the  Army  or  DISA  communication  planners,  but  it  may  also  be  a  function  of  the 
medical  Tri-Service  Infrastructure  Management  Program  Office  (TIMPO).  Rather  than  attempt 
to  sort  out  the  chain  of  responsibility  in  the  DoD,  this  report  contains  generic  recommendations 
equally  applicable  to  any  office  assigned  responsibility. 

TECHNICAL  APPROACH 

The  network  infrastructure  of  the  Army  MTFs  is  integrated  by  the  Army’s  regional  medical 
network,  MEDNET.  MEDNET  provides  high  quality  communication  links  among  the  MTFs, 
Army  command,  and  the  Internet.  DHIAP’s  RADIUS-compliant  system  can  use  MEDNET 
facilities  to  safely  integrate  multiple  RADIUS-compliant  systems  by  capitalizing  on  the  existing 
high  bandwidth  network  connections  and  the  regional  NT  domain  architecture  and  imposing  only 
a  slight  additional  load  on  the  wide  area  network. 

This  section  outlines  three  technical  approaches  to  implementing  DHIAP  RADIUS  compliance 
throughout  a  region.  The  first  approach  makes  each  site  autonomous  by  installing  a  complete 
DHIAP  prototype  configuration.  The  second  places  a  complete  DHIAP  prototype  configuration 
at  one  site  (assumed  to  be  the  location  of  region  headquarters)  and  has  all  other  sites  in  the  region 
communicate  with  the  central  regional  site  for  their  authentication,  authorization,  and  accounting 
services.  The  third  option  is  similar  to  the  second,  except  that  it  adds  a  second  (i.e.,  redundant) 


8  For  a  detailed  summary  of  findings,  refer  to  ATI  IPS  TR  00-02,  DHIAP  Phase  I  Composite  Evaluation  Report. 
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complete  configuration  at  one  of  the  region  sites  to  serve  as  backup  in  case  of  problems  with  the 
region’s  AAA  Server  (the  component  that  authenticates  the  remote  user).  Each  option  offers 
advantages  and  disadvantages,  reinforcing  the  importance  of  having  a  higher  echelon  authority 
determine  the  coordinated  technical  approach  to  be  followed  in  a  broad  implementation. 
Appendix  D  provides  a  technical  overview  of  the  DHIAP  equipment  configuration  and  the 
major  processing  steps  that  occur  during  the  Authentication,  Authorization,  and  Accounting  of 
the  DHIAP  RADIUS-compliant  process.  Operational  capabilities  offered  by  the  three  options 
are  summarized  in  the  sections  that  follow. 


Autonomous  Complete  RADIUS-Compliant 
Systems  at  Every  Site 

The  most  direct  implementation  option  in  a  region  is  to 
place  a  complete  RADIUS-compliant  system  (consisting 
of  AAA  Server  and  NAS)  at  each  MTF  site,  as  depicted  in 
Figure  7.  (This  is  the  approach  used  for  trial  site  testing 
of  the  DHIAP  prototype.)  The  solid  black  line  in  Figure 
7  indicates  that  each  site’s  authentication  is  performed 
locally;  the  dotted  line  indicates  the  authenticated  user’s 
access  to  network  resources.  The  demonstration 
configuration  shown  in  Figure  7  does  not  take  full 
advantage  of  the  system’s  capabilities  (e.g.,  it  offers  no 
backup  in  the  case  of  hardware  or  software  problems  in 
the  AAA  Server  or  NAS).  Benefits  of  the  configuration 
are  that  all  Authentication  /  Authorization  /  Accounting 
communications  are  local  to  the  site,  with  no  reliance  or 

additional  traffic  placed  on  the  MEDNET.  This  approach  utilizes  MEDNET  only  for  authorized 
user  communication  with  resources  at  distant  sites. 


Figure  7  -  Autonomous  Configuration  ■ 
Complete  Systems  at  All  Sites 


Complete  System  at  Central  Site  and  NAS  at 
All  Satellite  Sites 

A  second  option  for  regional  implementation  is  to 
install  a  complete  RADIUS-compliant  system  (NAS 
and  AAA  Server)  at  one  site  (e.g.,  at  the  region 
headquarters  location)  and  put  NAS-only  at  all  other 
locations  in  the  region  (e.g.,  MTF  and  clinics  with 
dial-in  users).  Here,  each  remote  NAS  interacts  with 
the  AAA  Server  at  the  Region  via  the  MEDNET. 
Figure  8  depicts  the  equipment  and  connectivity  in 
this  option;  the  solid  black  line  in  the  diagram 
indicates  the  processing  path  for  authenticating  a 
dial-in  user,  and  the  dotted  line  indicates  the  path  for 
user  access  to  network  resources.  The  difference 
between  this  processing  and  that  depicted  in  Figure  7 
is  that  a  NAS  is  physically  located  at  one  site  while 
its  AAA  Server  is  at  a  geographically  distant  site. 


◄ - ►  NAS-AAA  Authentication  communications 

* - ►  User’s  remote  system  access  thru  NAS 


Figure  8  -  Central  Configuration  -  Complete 
System  at  One  Site  and  NAS-Only  at  Remaining 
Sites 
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Due  to  the  minimal  amount  of  information 
passed  between  NAS  and  AAA  Server  (the 
User  ID  and  encrypted  password  in  a  120-byte 
package,  and  a  155 -byte  acknowledgement 
consisting  of  either  the  User  ID  and  the 
authorized  ACL  or  the  User  ID  a  denial 
indicator),  servicing  this  client-server 
relationship  via  the  T1 -speed  MEDNET  is 
feasible.  Based  on  the  current  bandwidth  of  the 
MEDNET  backbone,  the  amount  of  AAA 
traffic  across  the  system  will  have  a  minimal 
effect.  This  option  reduces  installation  cost 
since  only  the  cost  of  NAS  is  borne  for  the 
remote  sites.  In  addition,  it  reduces  the  cost  of 
system  administration  by  centralizing  most 
system  maintenance  and  administrative 
responsibilities  and  integrating  the 
administration  work  with  maintenance  and 
operation  of  the  existing  NT  Domain  Controller 
systems  at  the  central  location. 


◄ - ►  NAS-AAA  Authentication  communications 

* - ►  User’s  remote  system  access  thru  NAS 


Figure  9  -  Redundant  Configuration  -  Complete 
System  at  Two  Sites,  NAS-Only  at  Remaining  Sites 


Redundant  Complete  Systems  and  NAS 
at  Remaining  Satellite  Sites 

A  third  option  for  regional  implementation  is  to 


“ Region ” 
Complete 
System 


W  Remote 
►  "'Ji  User 


2nd 

Complete 

System 


- ►  NAS-AAA  Authentication  communications 

- ►  User’s  remote  system  access  thru  NAS 

X  Inoperable  component  and  communications 

■ . All  Authentication  (incl.  Region)  switched  to 

2nd  site 

Figure  10  -  Authentication  by  2nd  Site  AAA  Server 
When  Primary  AAA  Server  is  Not  Functioning 


install  a  complete  RADIUS-compliant  system 
(NAS  and  AAA  Server)  at  the  region,  install 
one  or  more  additional  complete  systems  at 
MTFs  in  the  region,  and  install  a  NAS  at  the 
each  of  the  remaining  sites  in  the  region.  All 
systems  are  connected  to  MEDNET,  allowing 
them  to  take  advantage  of  system  redundancy. 
Figure  9  depicts  the  equipment,  connectivity, 
and  data  flow  for  this  option  when  all 
elements  of  the  configuration  are  working 
properly.  Figure  10  depicts  operation  when 
the  primary  AAA  server  fails.  Because  of  the 
redundancy  of  complete  systems,  AAA  access 
for  the  entire  region  can  be  switched  from  the 
region  AAA  Server  to  the  “2nd  Site”  AAA 
Server.  Note  also  that  the  region’s  NAS 
switches  to  the  2nd  Site  NT  Domain  Controller 
for  authentication  of  its  users.  The  redundant 
configuration  option  reduces  cost  compared  to 
the  first  option  (autonomous  sites)  by 
installing  the  minimum  number  of  complete 
systems  and  using  NAS  at  the  rest.  The 
complete  sites  can  be  administered  by  the 
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region,  or  locally,  or  both. 

Note  on  Consequences  of  a  Non-Functional  NAS 

Figure  11  illustrates  that  loss  of  a  NAS  means  loss  of  dial-in  service  for  the  users  who  rely  on 
that  NAS.  Unless  its  users  have  been  provided  with  the  capability  of  dialing  to  an  alternate  NAS 
under  these  circumstances,  the  downed  NAS’  users 
are  prevented  from  accessing  network  resources 
until  the  failed  NAS  has  been  brought  back  online. 

Note  that  a  user  who  knows  the  dial-in  number  for  a 
different  NAS  in  the  region  is  able  to  connect  and 
use  network  resources  with  no  other  change  to  the 
dial-in  procedure. 


PROGRAM  MANAGEMENT  AND 
PROGRAMMATICS 

A  central  command  authority  should  commit  to 
using  a  coordinated  approach  for  MEDCOM's 
RADIUS  implementation.  Guidance  on  how  such  a 
project  will  proceed  should  include: 

•  Analysis  of  costs  (which  may  lead  to  Figure  11  -  Loss  of  Service  to  Users  When  Site 

revising  the  technology  approach),  is  Down 

•  Guidance  on  how  regions/sites  are  to  fund  the  implementation  costs, 

•  Development  of  requirements  and  guidance  for  project  implementation  by  the  region  and 
MTF-level  staffs, 

•  Definition  of  policy  and  general  procedures  for  use  of  the  implemented  system, 

•  Establishment  of  project  oversight  capabilities  (e.g.,  a  project  manager)  to  track  overall 
progress  and  deal  with  issues  as  they  arise,  and 

•  Assignment  of  responsibility  for  providing  technical  guidance  and  training  to  sites  on 
installing  and  maintaining  the  system. 

While  there  are  many  issues  requiring  resolution  in  the  above  listing,  this  section  of  this  report 
will  provide  information  useful  for  planning  for  funding,  training,  policy,  and  technical  guidance. 

Cost  Analysis 

The  funding  required  to  implement  the  RADIUS-compliant  technology  varies  with  the  approach 
selected  and  the  number  of  sites  to  be  installed.  As  described  previously,  the  configuration  for  a 
region  can  vary  from  autonomous  (a  complete  system  installed  at  every  site),  to  centralized 
(authentication/authorization  performed  at  one  site)  and  redundant  (the  centralized  option  with  a 
second  complete  system  available  to  assume  control  if  problems  are  encountered  at  the  central 
site).  Sample  costs  of  these  configuration  options  are  provided  in  Table  4.  Each  configuration 
shown  follows  an  assumption  that  there  ten  sites  in  a  region;  activity  at  the  Region  site  requires 
availability  of  twenty-four  modems,  five  sites  require  availability  of  sixteen  modems,  and  three 
small  sites  require  the  minimum  number  of  modems  (i.e.,  eight). 


“Region” 

Complete 

System 


( alternate  access  path 
if  user  knows  dial-in 
for  another  NAS) 


2nd 

Complete 

System 


-►  NAS-AAA  Authentication  communications 
j*  User’s  remote  system  access  thru  NAS 
V  Inoperable  component  and  communications 
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Table  4  -  Sample  Costs  for  DHIAP  Technology  Options 


Component 

■  Size  Options 

Autonomous  AAA 

Central  AAA 

Redundant  AAAs 

AAA/NAS  at 

All  10  Sites9 

AAA/NAS  at  Region  + 
NAS-Only  at  9  Sites9 

AAA/NAS  at  Region  and 
2nd  Large  Site  +  NAS-Only 
at  8  Sites9 

AAA 

Intel-based  PC  with  500  MHz  processor,  128 

MB  memory10 

2,850*  10  (All  Sites) 

2,850  *  1  ( Region ) 

2,850  *  2  (Region+2',d  Site) 

Windows  NT  Server  4.0  software  including 
Service  Pack  5.0 

800  *  10  (All  Sites) 

800  *  1  (Region) 

800  *  2  (Region+2"d  Site) 

CiscoSecure  ACS  2.4  software 

3,105  *  10  (All  Sites) 

3,105  *  1  (Region) 

3,105  *  2  (Region+2"d  Site ) 

NAS 

Cisco  3640  Router  with  one  of  the  following: 

■  24  modem  ports  -  56KB 1 1 

12,308  *  1  (Region) 

12,308  *  1  (Region) 

12,308  *  1  (Region) 

■  16  modem  ports  -  56KB 1 1 

10,812*6  (6  Sites) 

10,812  *6(6  Sites) 

10,812  *  6  (2nd  Site  +  5  Sites) 

■  8  modem  ports  -  56KB 1 1 

8,228  *  3(3  Sites) 

8,228  *  3(3  Sites) 

8,228  *  3(3  Sites) 

Other 

Equip 

1400V A  UPS 

700  *  10  (All  Sites) 

700  *  10  (All  Sites) 

700  *  10  (All  Sites) 

Open-sided  Hardware  Rack 

900  *  10  (All  Sites) 

900  *  10  (All  Sites) 

900  *  10  (All  Sites) 

Ann  $ 

First-year  Annual  Maintenance  for 

CiscoSecure  ACS  software12 

1,520*  10  (All  Sites) 

1,520  *  1  (Region) 

1,520  *  2  (Region+2’,d  Site) 

Ann  $ 

First-year  Annual  Maintenance  for  Cisco 

364012 

0 

950  *  9(9  NAS  Sites) 

950  *  8  (8  NAS  Sites) 

CONFIGURATION  COST  for  a  “REGION”13 

$200,614 

$134,689 

$142,014 

The  costs  shown  in  the  table  are  in  general  alignment  with  the  amount  of  capal 

bility  provided.  In 

the  scenario  shown,  note  that  the  autonomous  configuration  carries  a  30%  higher  cost  than  the 
other  options,  and  that  the  redundant  configuration,  which  offers  continuity  of  service,  is  only 
slightly  more  expensive  than  the  central  option. 

Planning  for  Region-  and  MTF-level  Projects 

Program  management  should  outline  project  requirements  for  the  distributed  organizations  that 
will  actually  perform  the  implementation  of  RADIUS -compliant  technology.  This  includes: 

•  A  briefing  for  region-  and  MTF-level  command  to  outline  the  purpose  of  the  effort  and 
initiate  activity  at  the  region  and  site  level 

The  briefing  should  provide  background  on  RADIUS  compliance,  funding, 
hardware/software  being  acquired,  resource  requirements  for  the  effort,  suspense  dates, 
etc. 

•  A  generalized  project  plan  for  region-  and  site-level  general  approaches  to 
implementing  the  RADIUS  technology. 

The  generic  plan  can  be  used  as  implementation  guidance  by  regions  and  sites.  By 
outlining  the  project’s  sequence  of  activities,  estimated  timeframes  for  completing  each 
major  activity,  and  types  of  staff/responsibilities  of  the  MTF  personnel  who  must 


9  The  equipment  features  and  costs  listed  in  Table  4  were  effective  in  March  2000.  This  summary  is  provided  for 
general  information  only.  The  Army’s  actual  cost  analysis  and  acquisition  decisions  should  be  based  on 
configuration  requirements,  product  features,  and  costs  as  of  the  date  of  configuration  analysis  and  acquisition. 

10  and  20  GB  hard  drive,  12/24  GB  DAT  (tape)  drive,  CD-ROM  drive,  3.5  diskette  drive,  Ethernet  card,  keyboard, 
mouse,  17"  monitor 

1 1  and  10/100  MB  Ethernet  card,  16  MB  non-volatile  memory,  Cisco  IOS  software 

12  Maintenance  is  a  recurring  cost  for  each  year  of  operation 

13  One-time  and  ongoing  costs  of  communications  services  is  not  included 
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participate  in  the  effort,  it  would  provide  the  operational  units  with  a  single,  consistent 
approach  to  performing  their  implementations.  In  addition,  the  plan  can  serve  as  a 
management  tool  for  overseeing  progress  of  the  distributed  efforts. 

•  Training  and  policy  documentation  to  be  incorporated  into  region-  and  site-level 
training  on  RADIUS  and  the  Army’s  selected  technical  approach 

Training  material  should  provide  a  starter  set  of  materials  that  each  facility  can  use  to 
train  its  management,  technical  staff,  and  users  on  the  purpose  and  use  of  the  RADIUS 
implementation.  Central  development  of  the  initial  package  will  allow  training  to  be 
consistent  across  sites  and  will  save  development  time  that  would  otherwise  be  expended 
at  every  affected  facility.  Excerpts  from  this  report  and  the  DHIAP  RADIUS 
Supplemental  Installation  and  Maintenance  Guide  (ATI  Special  Report  IPS  00-03)  should 
be  considered  as  resources  for  this  effort. 

Policy  and  Draft  Operational  Procedures 

Implementation  of  the  RADIUS-compliant  technology  advances  the  Army’s  security  capability 
in  several  areas.  In  addition  to  the  advances  in  user  identification,  limitation  on  remote  user 
access  to  systems,  and  accountability  that  are  the  specific  objective  of  a  RADIUS 
implementation,  the  implementation  will  also  provide  incentive  for  sites  to  examine  and  revise 
their  existing  security  policies  and  procedures.  In  mandating  RADIUS  compliance,  the  higher 
command  authority  should  provide  policy  guidance  sufficient  for  the  sites  to  properly  implement 
this  improved  security.  Providing  sample  procedural  documentation  with  the  policy  guidance 
will  ensure  that  each  site’s  procedures  conform  across  a  region  and  throughout  the  Army. 
Subjects  of  sample  procedure  are  likely  to  include:  the  methodology  for  users  to  request  remote 
system  access  (including  the  specific  systems  to  be  accessed);  region-wide  technical  procedure 
for  keeping  RADIUS  user  access  tables  synchronized  with  the  region’s  master  database  of  user 
access  permissions;  technical  procedure  for  maintaining  the  site’s  and  user’s  remote  access 
systems,  etc. 

Program  Oversight  and  Technical  Guidance 

A  designated  program  manager  should  be  assigned  responsibility  for  MEDCOM's  RADIUS 
implementation 

Since  the  implementation  of  RADIUS-compliant  technologies  is  a  technical  endeavor,  it  is  likely 
that  the  Army’s  region  and  site  MTF  staff  may  experience  some  technical  challenges  (as 
occurred  with  the  DHIAP  trial  sites).  Technical  issues  will  also  arise  from  the  rapid  pace  of 
change  in  the  technologies  required  for  a  RADIUS -compliant  system.  A  central  source  of 
knowledge,  with  ability  to  perform  specific  research  efforts  and  distribute  the  results  to  address  a 
problem,  will  be  a  useful  resource  for  all  MEDCOM  implementation  teams.  An  added  benefit  is 
the  Army’s  ability  to  learn  from  the  questions  being  asked  and  implement  a  program  of  notices 
or  training  enhancements  on  subjects  of  widely  experienced  problems. 

To  provide  an  appropriate  level  of  control  over  the  effort,  and  to  be  effective  in  intervening  when 
there  are  difficulties  or  delays,  the  following  actions  are  recommended: 

•  Appoint  a  project  manager  with  sufficient  authority  to  track  progress  and  deal  with  issues 
as  they  arise,  and 

•  Create  a  center  of  expertise  responsible  for  providing  technical  guidance  to  sites  on 
installing  and  maintaining  the  system. 
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The  experience  gained  by  DHIAP  demonstration  sites  should  be  a  resource  for  any  technology 
center  formed  for  this  program. 

Site  Considerations  for  Implementation 

The  predominant  effect  of  a  site’s  implementation  of  the  DHIAP-developed  RADIUS -compliant 
system  on  an  MTF  site  will  be  to  its  remote  system  users  and  certain  members  of  its  Information 
Management  Division  (IMD)  staff. 

•  The  site’s  remote  system  users  are  affected  in  two  ways.  First,  they  must  configure  their 
remote  computers  for  remote  access.  This  is  a  brief,  uncomplicated  procedure 
documented  in  the  DHIAP  RADIUS  Supplemental  Installation  and  Maintenance  Guide 
(ATI  Special  Report  IPS  00-03).  Second,  the  users  must  be  assigned  to  the  type  of  remote 
access  appropriate  to  their  role  at  the  facility.  (From  implementing  the  RADIUS- 
compliant  technology,  the  MTF  should  have  a  documented  procedure  for  this  activity.) 

•  The  effect  on  the  site’s  IMD  staff  will  vary  with  the  level  of  responsibility  carried  by  the 
site.  Responsibility  will  be  determined  as  part  of  the  region/MTF  planning  for  the 
installation,  in  concert  with  deciding  the  type  of  equipment  to  be  placed  there.  For 
example,  the  site  (e.g.,  region)  where  the  central  Complete  (AAA-NAS)  System  is 
installed  will  probably  be  responsible  for  installation  and  ongoing  maintenance  of  that 
system.  For  a  NAS-only  site,  responsibility  might  be  placed  at  the  MTF/clinic,  or  it 
might  be  carried  by  the  central  site. 

Table  5  provides  a  list  of  the  types  of  activity  that  IMD  will  perform  in  supporting  the  DHIAP 
prototype  technology,  the  DHIAP  team’s  recommendation  for  each  responsible  person’s  level  of 
experience  and/or  training,  and  an  estimated  time  requirement  to  perform  the  work. 


Table  5  -  Task,  Training,  and  Staffing  Requirements  to  Support  the  DHIAP  Technology 


Support  Task 

Type  of  IMD  Staff 

Training/Experience 

Required 

Estimated  Effort 

Prior  Experience 

System/Network 

Administrator 

1.  Basic  router 
configuration 

2.  Windows  NT  Server 
installation  and 
administration 

N/A 

Installation 

System/Network 

Administrator14 

1.  DHIAP  initial  training 
for  RADIUS  system 
administrator 

2. Self-study  and  hands-on 
experience 

1.  4  to  8  hours  training  in: 

■  Configuration  of  system 
parameters 

■  General  user  setup 

■  System  maintenance 

2.  Eight  hours  (approx.) 

Set  up  current  users 
for  RADIUS- 
controlled  remote 

access 

System 

Administrator 

N/A 

Varies  with  number  of  users 
(@2  to  5  minutes/user)  to: 

■  Establish  and  configure 

AAA  Access  Control  List 

■  Enroll  users  into 
appropriate  ACL  groups 

Note  that  a  minimum  of  two  system  administrators  should  be  trained  in  order  to  have  adequate  staffing  backup. 
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Table  5  -  Task,  Training,  and  Staffing  Requirements  to  Support  the  DHIAP  Technology 


Support  Task 

Type  of  IMD  Staff 

Training/Experience 

Required 

Estimated  Effort 

Ongoing  system 
and  user  database 
maintenance 

System 

Administrator 

N/A 

Varies  with  number  of  users: 

■  Set  up  user  restrictions 

■  Update  users'  group 
assignments 

■  Update  AAA  Access 

Control  List 

For  all  of  the  work  outlined  in  Table  5,  the  DHIAP  RADIUS  Supplemental  Installation  and 
Maintenance  Guide  ( ATI  Special  Report  IPS  00-03)  provides  useful  general  information  and 
instruction. 
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Reference  Materials 


The  following  materials  were  used  as  reference  materials  by  participants  of  the  DHIAP  Phase  I 
effort. 


•  AR  380-19,  Information  System  Security,  27  February  1998 

•  AR  380-53,  Information  Systems  Security  Monitoring,  29  May  1998 

•  MCUB-AS  (25),  Memorandum  of  Instruction:  Release  of  Medical  Information  and 
Freedom  of  Information  Act  Processing 

•  MEDDAC  Regulation  190-51, 

•  Military  Health  Services  System  (MHS)  Automated  Information  Systems  (AIS)  Security 
Policy  Manual,  Version  1.0,  April  1996 

•  Department  of  Defense  Technical  Architecture  Framework  Information  Management, 
Volume  6:  DoD  Goal  Security  Architecture,  Version  3.0,  30  April  1996 

•  Army  Medical  Department  (AMEDD)  Information  Systems  Security  Plan  (undated) 

•  Risk  Analysis,  MEDCOM  Network  Security  Project,  Prepared  by  Science  Applications 
International  Corporation,  February  5,  1997,  for  Tripler  Regional  Medical  Center 

•  Local  policy  memorandum  and  regulations  on  Personnel  and  Physical  Security  Program 
and  Security  Standards  for  Automation  Data  Processing 

Note  that  the  pending  legislation  and  regulatory  guidance  of  Health  Insurance  Portability  and 
Accountability  Act  of  1996  (HIPAA),  expected  to  be  effective  during  2000  and  requiring 
compliance  about  two  years  afterwards,  will  also  affect  requirements  for  privacy  of  individually 
identifiable  health  information.  It  is  expected  that  HIPAA  requirements  will  be  incorporated  into 
requirements  of  the  Joint  Commission  on  Accreditation  of  Healthcare  Organizations. 
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Army  Dial-in  Modem  Standards  and  Policy 


Subject:  [R]  NETWORK  SECURITY  IMPROVEMENT  PROGRAM  (NSIP)  -  ARMY 
Author:  Dolores  Perez  at  MEDCOM2_FSHTX 
Date:  4/27/99  9:49  AM 

RTTUZYUW  RUEAUSA9699  1131825-UUUU  -RUERSHA. 

ZNR  UUUUU 
R  231300Z  APR  99 

FM  HQ  WASHINGTON  DC//SAIS-IAS// 

SUBJECT:  NETWORK  SECURITY  IMPROVEMENT  PROGRAM  (NSIP)  - 
ARMY  MODEM  DIAL-IN  STANDARDSAND  POLICY. 


1.  The  purpose  of  this  message  is  to  provide  standards  and  policy  for  the  implementation  of 
protected  dial-in  systems  Army-wide.  Dial-in  systems  can  be  an  exploitable  entry  point  into 
the  information  backbone.  Installation  DOIMs  must  ensure  that  all  Army  dial-in  operations 
to  include  information  technology  functions  adhere  to  the  standards  stated  in  this  message. 
This  message  applies  to  the  active  Army,  the  Army  National  Guard,  and  the  U.S.  Army 
Reserve. 

2.  Army  dial-in  users  will  be  required  to  migrate  to  an  identification  and  authentication  (I&A) 
system  that  will  authenticate  all  dial-in  operations  with  a  unique  user-id  and  password,  that  is 
compliant  with  the  remote  authentication  dial-in  user  system  (RADIUS)  Standard,  nit  one 
calendar  year  from  the  dtg  this  message.  The  standards  for  such  a  system  are: 

A.  All  dial-in  operations  will  be  authenticated  with  a  unique  user-id  and  password. 
Passwords  shall  be  at  least  eight  randomly  generated  alphanumeric  characters  and 
reflect  the  current  Army  password  expiration  policy  of  6  months. 

B.  I&A  systems  supporting  dial-in  capabilities  will  migrate  to  the  JTA  compliant 
RADIUS  standard.  The  RADIUS  software  shall  be  configured  for  accounting. 
Accounting  logs  will  at  a  minimum  show  who  logged  in,  when  they  logged  in,  and  be 
stored  for  a  year. 
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C.  All  I&A  servers  will  be  protected  with  a  host  based  ids.  I&A  server  managers  and 
DOIMs  are  responsible  for  operating  and  auditing  the  ids  results. 

D.  The  MACOM  Information  Assurance  (IA)  officer  will  be  responsible  for  reporting 
the  location/ip  address/hardware  platform  and  version  of  the  os  of  the  I&A  servers  to 
the  odisc4  poc  for  this  message. 

E.  All  I&A  servers  will  be  remotely  audited  to  ensure  all  Army  IA  standards  established 
in  this  message  are  met.  Recommend  that  DOIMs  place  I&A  servers  in  a  DMZ.  The 
odisc4  poc  this  message  will  coordinate  the  remote  configuration  audits  with  the 
MACOM  IA  officer. 

3.  The  following  actions  must  be  considered  when  setting  up  a  authentication  system. 

A.  If  necessary,  users  must  upgrade  local  terminal  servers  to  be  RADIUS  compliant. 
Cisco  terminal  servers  running  IOS  11.2  or  greater  are  RADIUS  compliant.  The 
Army  disn  router  program  upgraded  the  old  CISCO  asm  terminal  servers  to  CISCO 
5200  terminal  servers.  The  old  CISCO  asm  terminal  servers  cannot  run  IOS  11.2  and 
must  be  upgraded  or  removed  from  operation. 

B.  Microsoft  RAS  must  be  configured  to  allow  tcp/ip  or  ipx  clients  access  only  to  the 
local  network.  Care  should  be  taken  when  configuring  user  dial-in  accounts.  If  a 
dial-in  system  is  intended  to  restrict  access  to  a  local  network,  then  users  will  be 
required  to  log-off  before  attempting  to  access  a  different  local  network. 

C.  The  Microsoft  RAS  must  be  configured  to  ensure  that  passwords  are  encrypted. 

D.  Microsoft  remote  access  servers  will  be  placed  in  the  DMZ  and  must  be  configured 
for  RADIUS  and  host-based  ids. 

4.  DOIMS  must  ensure  that  any  dial-in  systems  that  are  connected  to  the  installation  data 
networks,  that  they  own  or  operate,  adhere  to  these  RADIUS  standards.  If  they  do  not,  they 
must  be  disconnected.  Those  systems  that  are  not  owned  or  operated  by  the  post,  camp  or 
installation  DOIM  and  are  not  willing  or  able  to  meet  Army  standards  must  be  reported  to  the 
odisc4  poc  for  this  msg. 

5.  Stand  alone  dial-back  modems  and  modem  systems  that  authenticate  using  RADIUS  are  the 
only  allowable  modems.  Without  aggressive  action,  dial-in  systems  and  stand-alone  modems 
will  continue  to  be  a  potential  backdoor  for  unauthorized  intruders. 

6.  odisc4  pocs  for  this  message  are: 

A.  Ltc  Lundgren  dsn  664-8377,  email  lundgl@hqda.Army.mil 

B.  Mr.  Phillip  Loranger  dsn  327-5887,  cmcl  703-607-5887,  email 
lorangep@hqda.Army.mil 

7.  asc  technical  pocs  are: 

A.  Mr.  Robert  Manning  dsn  879-8195,  email  manningr@hqasc.Army.mil 

B.  Mr.  Peter  E.  Pietras,  dsn  879-8195,  cmcl  (520)  538-8195,  pietrasp@hqasc.Army.mil 

C.  Mr.  Sam  Dean,  deans@hqasc.Army.mil,  dsn  821-4987,  cmcl  (520)  533-4987. 
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Overview  of  IETF  Internet  Standard  Protocol  for  RADIUS 


RADIUS  is  an  Internet  standard  protocol  “for  carrying  authentication,  authorization,  and 
configuration  information  between  a  Network  Access  Server  which  desires  to  authenticate  its 
links  and  a  shared  Authentication  Server.”15  As  described  in  the  protocol,  “managing  dispersed 
serial  line  and  modem  pools  for  large  numbers  of  users  can  create  the  need  for  significant 
administrative  support.  Since  modem  pools  are  by  definition  a  link  to  the  outside  world,  they 
require  careful  attention  to  security,  authorization  and  accounting.  This  can  be  best  achieved  by 
managing  a  single  “database”  of  users,  which  allows  for  authentication  (verifying  user  name  and 
password)  as  well  as  configuration  information  detailing  the  type  of  service  to  deliver  to  the  user 
(for  example,  SLIP,  PPP,  telnet,  rlogin).  Key  features  of  RADIUS  are: 

•  Client/Server  Model 

A  Network  Access  Server  (NAS)  operates  as  a  client  of  RADIUS.  The  client  is 
responsible  for  passing  user  information  to  designated  RADIUS  servers,  and  then  acting 
on  the  response  that  is  returned. 

RADIUS  servers  are  responsible  for  receiving  user  connection  requests,  authenticating 
the  user,  and  then  returning  all  configuration  information  necessary  for  the  client  to 
deliver  service  to  the  user. 

A  RADIUS  server  can  act  as  a  proxy  client  to  other  RADIUS  servers  or  other  kinds  of 
authentication  servers. 

•  Network  Security 

Transactions  between  the  client  and  RADIUS  server  are  authenticated  through  the  use  of 
a  shared  secret,  which  is  never  sent  over  the  network.  In  addition,  any  user  passwords  are 
sent  encrypted  between  the  client  and  RADIUS  server,  to  eliminate  the  possibility  that 
someone  snooping  on  an  unsecure  network  could  determine  a  user’s  password. 


15  Internet  Engineering  Task  Force  (IETF)  Network  Working  Group  document;  URL  for  the  IETF  RADIUS 
standard  (rfc  2138)  is  http://www.ietf.org/rfc/rfc2138.txt 
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The  standard  describes  the  protocol  for  “AAA,”  or  Authentication,  Authorization,  and  Accounting 
of  dial-in  users  who  request  access  to  a  network  and  its  resources. 

•  Authentication  assures  that  a  user  is  who  he  claims  to  be.  It  is  accomplished  by 
verifying  the  User  ID  and  Password  provided  when  the  user  initially  attempts  to  access 
the  network. 

•  Authorization  limits  the  authenticated  user’s  access  to  predetermined  resources.  It 
intercepts  the  user’s  attempt  to  access  a  network  resource  and  verifies  whether  access  to 
that  resource  is  permitted. 

•  Accounting  maintains  a  log  of  session  statistics.  Logging  entries  can  include,  but  are  not 
limited  to,  login  and  exit  time,  user  IP  Address,  user  name,  Network  Access  Server 
(NAS)  entry  port,  and  denial  of  login  privileges. 


Appendix  Page  30 


ATI  IPT  TR  00-04 


DHIAP  PROTOTYPE  IMPLEMENTATION 


APPENDIX  D 


Appendix 

D 


DHIAP  Prototype  Implementation 


Equipment  Configuration 

Components  of  the  prototype  RADIUS  - 
compliant  system  used  in  the  DHIAP 
demonstration  are  shown  in  Figure  Dl.  The 
hardware  consists  of  an  Intel-based  computer,  a 
router  capable  of  housing  8,  16,  24,  or  32 
modems  (as  required  by  the  site),  an 
uninterruptible  power  supply  (UPS),  and  a 
mobile  tower  rack  to  house  them  all. 


RADIUS  AAA  Server 

Authentication  /  Authorization  / 
Accounting 


NAS  f 

Network  Access  Server 

ups 

Uninterruptible  Power  Supply 


Software: 

•  Windows  NT  Server  4.0, 
including  Service  Pack  4.0 

•  CiscoSecure  ACS  2.4 

•  APC  PowerChute  Plus  (for 
UPS) 

Hardware: 

•  Compaq  AP500 

•  Pentium  III  500  MHz  processor 

7*  128  MB  memory 

•  9  GB  hard  drive 

•  12  GB  DAT  (tape)  drive 

•  17  "monitor 

•  56  KB  modem 

•  Ethernet  card 

The  Intel-based  computer  is  established  as  the 
RADIUS  AAA  Server  by  loading  it  with  and 
configuring  Windows  NT  Server,  Internet 
Information  Services  (IIS),  and  CiscoSecure 
ACS  software.  The  router  is  established  as  the 
RADIUS  Network  Access  Server  (NAS)  by 
configuring  its  IOS  software  with  commands 
that  enable  it  to  work  with  the  AAA  Server. 

The  UPS  is  configured  by  installing  its  APC 

PowerChute  Plus  software  on  the  NT  Server  (the  Intel-based  computer). 


Software: 

•  Cisco  IOS  12.0 


lard  ware: 

•  Cisco  3640  router 

•  24  56  KB  modems 

(8-port  +  16-port  analog  modem  modules) 
10/100  MB  FastEthernet  card 
16  MB  non-volatile  memory 


Figure  Dl  -  Components  of  the  DHIAP 
Demonstration’s  RADIUS-compliant  System 


Processing  Flow 

Authentication 

The  DHIAP  demonstration’s  RADIUS-compliant  system  is  designed  for  implementation  at  the 
point  of  dial-in  access  of  each  MTF’s  existing  network  infrastructure.  Figure  D2  provides  a 
diagram  and  brief  explanation  of  the  basic  processing  for  authentication  of  a  remote  user.  Note 
that,  by  using  the  region’s  NT  Domain  Controller  architecture  as  its  authority  for  authentication, 
the  DHIAP  approach  utilizes  the  region’s  existing  central  resource  for  controlling  its  users’  User 
ID/Password  pairs,  greatly  simplifying  implementation  and  maintenance  of  the  RADIUS- 
compliant  system. 
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Authorization 

For  authorization,  the  process  that  is  executed  each  time  an  authenticated  user  requests  access  to 
a  different  network  resource,  the  NAS  uses  the  access  permissions  previously  provided  by  the 
AAA  Server  during  the  authentication  process  to  determine  whether  to  permit  or  deny  the 
request.  Information  defining  the  system  resources  that  a  dial-in  user  may  access  was  transferred 
during  authentication  from  the  AAA  Server’s  User  Database  to  the  NAS,  where  it  is  held  in 
memory  for  the  duration  of  the  user’s  online  session.  The  CiscoSecure  software  on  the  AAA 
Server  permits  definition  of  up  to  99  Access  Groups  for  the  Access  Control  List  used  as  the  NAS 
authorization  resource.  Each  Access  Group  is  defined  by  the  system  administrator  to  represent  a 
unique  mix  of  resources  offered  at  the  site.  (Note  that  a  typical  site  is  likely  to  use  only  2  to  4 
groups.)  Besides  identifying  the  network  resources  to  be  allowed  or  denied,  these  access 
permissions  allow  for  such  control  features  as  limits  on  the  time  of  day  when  remote  login  is 
permitted  for  the  user  and  restrictions  on  the  dial-in  port  from  which  the  user  may  work.  Figure 
D3  depicts  a  remote  dial-in  session  and  several  resources  that  might  available  on  the  network, 
and  indicates  whether  the  user  is  permitted  access  to  them.  Note  that  all  communications  during 
the  remote  session  pass  only  through  the  NAS  after  the  user  is  authorized,  no  longer  involving 
AAA  Server  processing. 

For  situations  where  a  first-time  remote  user  is  known  to  the  NT  User  Database  and  authorized 
for  remote  access  but  not  yet  defined  in  the  AAA  Server,  the  NAS  is  typically  configured  to 
automatically  assign  the  user  to  its  “default”  Access  Group.  Resource  permissions  for  default 
access  are  usually  very  limited  (e.g.,  e-mail  only).  A  formal  procedure  at  the  facility  that 
involves  the  user,  management,  and  system  administrator  would  then  be  followed  to  assign  the 
user  to  a  different  remote  Access  Group  that  offers  resources  more  appropriate  to  the  user’s  role 
at  the  facility;  the  user’s  next  remote  session  would  then  be  managed  by  the  NAS  in  accordance 
with  the  newer  entry.  Note  that  the  Access  Group  assignment/ Access  Control  List  entry  does  not 
necessarily  grant  remote  users  the  same  types  of  access  they  enjoy  when  working  onsite.  For 
example,  a  nurse  who  uses  NT  Office  functions  and  CHCS  when  onsite  might  be  denied  outside 
access  to  CHCS  but  permitted  access  to  NT  Office  functions. 

Accounting 

As  it  completes  each  step  of  the  authentication  process,  the  AAA  Server  records  session  statistics 
on  the  Accounting  Log  file.16  The  systems  administrator  may  customize  the  information  that  is 
recorded  on  the  log,  typically  including  for  all  log  on  attempts,  both  successful  and  failed,  the 
user’s  User  ID,  login  port,  login  time,  and  the  IP  address  used  for  the  session.  AAA 
administrative  software  allows  the  system  administrator  to  alter  the  log’s  categories  of 
information  capture  as  the  needs  of  the  site  change.  The  software  also  allows  for  configuring  the 
Accounting  process  to  generate  an  automated  warning  when  a  questionable  activity  occurs.  For 
instance,  detection  of  repeated  unsuccessful  login  attempts  could  generate  an  e-mail  message  or  a 
page  to  a  system  administrator  so  that  the  suspicious  activity  could  be  investigated  immediately. 


16  AAA  Server  logging  records  events  related  to  network  access.  It  is  not  related  in  any  way  to  the  type  of  logging 
performed  in  some  application  systems,  which  often  records  events  related  to  user  access  and  modification  of  the 
application’s  data  records  and  data  elements. 
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Figure  D2  -  AUTHENTICATION/ACCOUNTING  for  Remote  User  Access  to  Network  Resources 

The  numbers  used  in  the  steps  below  relate  to  the  circled  numbers  in  the  diagram  to  the  left. 

1.  Remote  user  dials  into  the  local  site,  providing  User  ID  and  Password 

2.  NAS  accepts  user  input,  sends  User  ID/Password  pair  to  AAA  Server  for  Authentication  (password  is  sent 
in  encrypted  format) 

3.  AAA  Server  accesses  the  AAA  User  Database  to  determine  whether  User  ID/Password  pair  is  valid;  if 
found  and  pair  is  valid  (i.e.,  OK),  bypass  step  4  below  and  go  to  step  5 

If  User  ID/Password  pair  is  not  found  in  the  AAA 
User  Database,  AAA  Server  queries  the  NT  Server  for 
Authentication  as  follows: 

4. a.  NT  Server  accesses  NT  User  Database  to 
determine  whether: 

■  User  ID/Password  pair  is  valid,  and 

■  User  is  authorized  for  remote  access  to  network 
resources 

4.b.  Based  on  4a  results,  NT  Server  returns  one  of  the 
following  Authentication  results  to  AAA  Server: 

■  OK  if  User  ID/Password  pair  is  valid  and 
remote  access  is  permitted 

■  NOT  OK  if  User  ID/Password  pair  is  valid  but 
remote  access  is  not  permitted 

■  NOT  OK  if  User  ID/Password  pair  is  invalid 

5.  If  result  from  step  3  or  NT  Server’s  result  from  step  4b  is  OK,  AAA  Server  uses  User  ID  to  acquire  the 
user’s  Access  Control  List  reference  information  from  AAA  User  Database.  AAA  Server  sends  its 
Authentication  result  to  NAS  as  follows: 

■  If  OK,  AAA  sends  an  acceptance  indicator  and  the  user’s  Access  Control  List  reference  information  to 
NAS 

■  If  NOT  OK,  AAA  sends  a  rejection  indicator  to  NAS 

6.  AAA  Server  logs  the  user’s  access  request  and  OK/NOT  OK  disposition  to  the  Accounting  Log  file 

7.  NAS  concludes  Authentication  as  follows: 

7. a.  USER  ACCEPTED :  Based  on  AAA  Server’s  Access  Control  List  reference,  NAS  establishes  user’s 
Access  Group  for  the  session  and  proceeds  to  Authorization 
7.b.  USER  REJECTED :  NAS  sends  rejection  notification  to  user,  terminates  session 
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Acronyms 


Acronym  / 
Term 

ADL 

ATI 

CHCS 

CIO 

Cisco 

DHIAP 

DISA 

DISC4 

DOD 

HIPAA 

HOST 

IETF 

IOS 

IP 

ISE 

IT 

LMES 

MEDCOM 

MRMC 

MTF 

OSD(HA) 

PC 

RADIUS 

SEI 

TATRC 

TCP 

TIMPO 

UPS 


Meaning 

Arthur  D.  Little 

Advanced  Technology  Institute 
Composite  Heath  Care  System 
Chief  Information  Officer 

Vendor  of  hardware  and  software  used  in  the  DHIAP  demonstration 
Defense  Healthcare  Information  Assurance  Program 
Defense  Information  Systems  Agency 

Directorate  of  Information  Systems,  Command,  Control,  Communications,  and  Computers 
Department  of  Defense 

Health  Insurance  Portability  and  Accountability  Act  of  1996 

Healthcare  Open  Systems  and  Trials 

Internet  Engineering  Task  Force 

Internet  Operating  System  (Cisco’s  operating  system) 

Internet  Protocol 
Information  Security  Evaluation 
Information  Technology 
Lockheed  Martin  Energy  Systems 
Medical  Command 

Medical  Research  and  Material  Command 

Medical  Treatment  Facility 

Office  of  Secretary  of  Defense  (Health  Affairs) 

Personal  Computer 

Remote  Authentication  Dial-In  User  Service 
Software  Engineering  Institute 

Telemedicine  and  Advanced  Technology  Research  Center 
Transmission  Control  Protocol 

Tri-Service  Infrastructure  Management  Program  Office 
Uninterruptible  Power  Supply 
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